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SYSTEM AND METHOD FOR REPORTING CALLS 

REFERENCE TO PROVISIONAL APPLICATION 
The present application hereby makes reference 
to and claims priority from Provisional Patent 
5 Application No. 60/108,731, filed November 17, 1998, 
entitled System and Method for Reporting Calls. 

BACKGROUND OF THE INVENTION 
The present invention deals with call record 
reporting. More specifically, the present invention 
10 deals with arranging and reporting call record 
information to customers using, in some cases, 
geographically descriptive information. 

Current telecommunications networks are 
capable of tracking and recording call transaction data, 
15 i.e., information associated with a given telephone 
call, and using this data to support call processing and 
to provide accurate billing information to customers. 
Systems have also been developed which strive to provide 
the customer with quite detailed call transaction data 
20 which the customer may use for specific purposes. U.S. 
Patent No. 5,425,087 to Gerber, for example, discloses 
a system that reports the length of each call, the 
length of time that a party was placed on hold, and the 
telephone number of the other party to a system 
25 administrator so that the telephone activities of 
employees can be monitored in real time. 

U.S. Patent No. 5,754,634 to Kay, et al . 
discloses a system for tracking calls made to individual 
predetermined subscribers and automatically reporting 
30 information, including demographic breakdowns of calls, 
such as time of day, day of week, and location of 
origin, to the subscriber. The disclosed system makes 
use of the Advanced Intelligent Network (AIN) and 
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Integrated Service Control Point (ISCP) platform to 
provide such information to those subscribers desirous 
of such service. The ISCP captures the time and date of 
the call, the originating call number and the 
5 subscriber's call number. ISCP network data is 
collected for all calls placed to service subscribers by 
the AIN Data and Reports System (DRS) . DRS is an 
. operation support utility that provides service analysis 
on the collected data. The data may be sorted on the 
10 basis of called subscriber number and transmitted at 
periodic intervals to a report processor. 
...^ The call originating telephone number for each 

call may be used to access an existing telephone system^ 
'-'2 billing database to obtain caller information, including 

15 zip code. The zip code, in turn, can be used to access, 
ily a commercially available census database to. provide. 

further demographic information. For example, . 

i y 

n demographics for a given zip code may include median age ^ 

j'" and median income. Report statistics can match these 

2 0 demographics with a number of calls received as 

collected at the ISCP. 
''i The calling party number may be supplied 

through Caller ID or AIN transmission. If this 
information is available only for calls within a 
25 telephone company Local Access and Transport Area 
(LATA) , reports may include detailed breakdown of such 
calls while categorizing out of LATA calls in more 
general breakdowns. Detailed zip code results can 
include number and percentage of residential calls, 

3 0 business calls, homeowners, median income and age. 

Generalized information may include numbers, averages 
and percentages of calls in time ranges for days of the 
week . 




The existing arrangements have some drawbacks. 
In the existing arrangements, a zip code cannot be 
attached to certain calls. For example, because a 
telephone company has no billing records for telephone 
5 numbers outside of its LATA, it cannot attach a zip code 
to long distance calls. Further, under the existing 
arrangement, there is no way to attach a geographical 
indicator to a call without a zip code. Thus, for many 
calls, no geographical indicator can be attached. 

10 Furthermore, even for calls for which a zip code is 
attached, there is no indication of an actual geographic 
location. All the subscriber receives is a zip code. 
Another drawback of the existing arrangements is that 
the report that is output to the subscriber is only 

15 available in tabular form, which tends to be rather 
cryptic. Thus, it is difficult and inconvenient for the 
subscriber to comprehend and absorb the information 
contained in the tables. 

SUMMARY OF THE INVENTION 

20 The present invention can be configured to 

provide one or more of a variety of advantages. Among 
the advantages are the flexibility and convenience that 
it affords the subscriber in choosing the output format 
in which to view the call data reports. The subscriber 

25 has the option of viewing the information in the form of 
tables, graphs or maps of a multitude of different 
formats. Particularly advantageous are the various map 
report formats, which allow the subscriber to easily 
visualize and digest the information provided by the 

3 0 system. Another advantage of the present invention is 
its ability to attach a geographical location to calling 
parties for whom a corresponding zip code is not 
available. Yet another advantage of the present 
invention is that it verifies the validity of the call 
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transaction data before proceeding with the processing 
of the data. 

The present invention is a system and method 
for processing and reporting telephone records. The 
5 system first receives call transaction data from a 
telephone company. The system verifies the validity of 
the data before proceeding with processing the data. 
Next the data is geocoded so that the calls can be 
traced to a given location. A report generator then 

10 uses the call detail data to generate reports relating 
to the call detail data. 

The report generator may be operated by the 
provider of the service embodying the present invention, 
or may be operated by the subscriber to the service on 

15 the subscriber's -own computer, depending on the 
preference of the subscriber. Where the service 
provider generates the reports, a paper copy of the 
reports in formats selected by the subscriber is 
delivered to the subscriber. If the subscriber elects 

20 to generate the reports, the call detail data is 
delivered to the subscriber via means selected by the 
subscriber, illustratively via a computer network or on 
diskette. The report generator produces tables, graphs, 
and maps which are useful to the subscriber. When 

25 generating maps, the report generator uses the geocoded 
information to geographically locate given calls on a 
map. 

The subscriber may use generated reports to do 
detailed marketing research. For example, the 

30 subscriber can determine from which geographical areas 
the greatest response was received following, for 
example, a given television advertisement and adjust its 
advertising strategy accordingly. The subscriber may 
also use the generated reports to assist in staffing 
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decisions. For example, the subscriber can determine 
when during the day, and on which lines, incomining 
calls were unanswered or met with busy signals. 

BRIEF DESCRIPTION OF THE DRAWINGS 
5 FIG. 1 is a high level block diagram of a 

system utilizing the present invention. 

FIG. 2 is a functional block diagram 
illustrating one embodiment of telephone company call 
processing. 

10 FIG. 3 is an example of a call record, which 

is provided by the telephone company for processing by 
the present invention. 

FIG. 4 is a functional block diagram 
illustrating one embodiment of call processing according 
15 to the present invention. 

FIG. 5 is a functional block diagram- 
illustrating one embodiment of end-of -cycle processing 
according to the present invention. 

FIG. 6 is a functional block diagram 
20 illustrating one embodiment of web report distribution 
according to the present invention. 

FIG. 7 is a functional block diagram 
illustrating one embodiment of diskette report 
distribution according to the present invention. 
25 FIG. 8 is a table exemplifying call detail 

data that may be produced according to the present 
invention . 

Table 1 demonstrates the geocoding logic 
hierarchy according to the present invention. 
3 0 Appendix A contains an exemplary view of a 

computer screen that may be generated according to the 
present invention . 
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Appendix B contains an exemplary view of a 
computer screen that may be generated according to the 
present invention . 

Appendix C contains an exemplary view of a 
5 computer screen that may be generated according to the 
present invention . 

Appendix D contains a table exemplifying a 
report that may be generated by the report generator 
according to the present invention. 
10 Appendix E contains a graph exemplifying a 

report that may be generated by the report generator 
according to the present invention. 

Appendix F contains a map exemplifying a 
report that may be generated by the report generator 
15 according to the present invention. 

Appendix G contains a map exemplifying a 
report that may be generated by the report generator 
according to the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
20 FIG. 1 provides an overview of the system of 

the present invention. FIG. 1 shows in block diagram 
form, telephone company 10, service provider 14, and 
customer 26. In block 10, the telephone company 
captures and processes call transaction data for a 
25 customer who subscribes to a reporting service employing 
the system of the present invention. In block 12, the 
telephone company transmits the call records, via a 
global computer network (such as the Internet) or other 
appropriate means, to the provider of the service 
3 0 embodied in the present invention. 

In block 14, the service provider processes 
the call records received from the telephone company. 
In order to do this, a number of functions are 
performed. The functions are illustrated by blocks in 
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service provider call processing block 14, and can be 
performed by any suitable, computer-based systems. In 
block 16, the system converts the call record data into 
a format that is compatible with the system's geocoding 
5 software and report -generating software. Also in block 
16, the call records are matched to the subscriber. In 
block 18, the system audits and verifies the validity of 
the data. In block 20, the system geocodes the call 
data. Thus, for each call, the system attaches a 

10 geographic longitude and latitude corresponding to the 
location of the second party to the call (the subscriber 
being the first party to the call) . In block 22, the 
call records and the geocoded data are packaged into a 
call detail file. In block 24, the call detail data is 

15 delivered to the subscriber in a suitable way, such as 
via the Internet, on floppy disk or in paper form. 



is fed into a report generator which outputs a report in 



20 generator is run by the subscriber on the subscriber's 
own computer (unless the subscriber opts for paper 
delivery, in which case the service provider generates 
the report) . The available report formats include a 
variety of tables, graphs and maps. If the subscriber 

25 selects the map format, the report generator overlays 
the geocoded data on a map so that the subscriber can 
see on the map exactly where calls were placed to or 
received from along with various other information 
regarding those calls. 

30 FIG. 2 provides an illustrative example of the 

call processing performed by the telephone company as 
shown in block 10 of FIG. 1. It should be noted that 
different telephone companies will process their call 
records in different ways. The present invention is 



Block 26 illustrates that the call detail data 



a format selected by the subscriber. 



The report 
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capable of adjusting to the particular processing method 
employed by a given telephone company. It should also 
be noted that different telephone companies will 
transmit their call records to the service provider at 
5 different points along the chain illustrated in FIG. 2. 



telephone company captures call transaction data off of 
the Advanced Intelligent Network (AIN) and places the 
data in AIN call files 30 of two types: call attempt 

10 files and completed call files. The call attempt files 
contain call transaction data for all attempted calls, 
while the completed call files contain call transaction 
data only for calls that were answered. Call 
transaction data can include the time, date and duration 

15 of the call, the originating call number, the 
terminating call number, and call status (busy, answered 
or unanswered) . Because the present invention can be 
used with both outgoing and incoming calls, the 
subscriber's line number may be either the originating 

20 or the terminating call number. The telephone company 
then combines the AIN call files from its various 
switches into a single call attempt file and a single 
completed call file, as shown in block 32. 



25 billing telephone number (BTN) and zip code, of the 
second party to each call are added to the call 
transaction data files. Billing records may not be 
available for some calls (long distance calls, for 
instance) . In this illustrative embodiment, the step 

30 embodied in block 34 is performed by the telephone 
company. However, the present invention is also capable 
of performing this step, as well as all subsequent 
steps . 



In FIG. 2, 



at its various switches 28, the 



In block 34, the billing records, including 
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Next, the AIN call attempt file 36 and the AIN 



completed call file 38 are combined to form one complete 
call record file, as shown in block 40. This call 
record file is then transmitted to the service provider 
5 by sending it to the service provider's FTP (File 
Transfer Protocol) server 42, or other appropriate 
means. In one illustrative embodiment, the telephone 
company will transmit the call record data to the 
service provider at least daily. 

10 FIG. 3 is a printout of a sample single call 

record 44 that might be transmitted from the telephone 
company to the service provider. Some of the 
significant fields include the subscriber billing 
telephone number 46, the number of the subscriber's line 

15 48 used for the call, the time 50 and date 52 of the 
call, the line number of the call party 54, the zip code 
of the calling party 56, call type 58 and duration 60. 
Different telephone companies may transmit call records 
of varying formats. For instance, the call type field 

20 58 of one telephone company might indicate whether the 
call was answered, unanswered or met with a busy signal, 
while for a different telephone company might indicate 
whether the call was incoming or outgoing. Also, the 
subscriber has the option of receiving records for 

25 incoming calls, outgoing calls or both, and the call 
record will vary accordingly. 



call processing performed by the service provider as 
shown in block 14 of FIG. 1. The service provider 
30 receives the call record files from the telephone 
company by any appropriate means. In FIG. 4, the 
service provider receives the call record data at its 
secured FTP server 42, as shown in block 62. In block 
64, the FTP server is scanned for files received. Also 



FIG. 4 provides a detailed breakdown of the 
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in block 64, when raw files 66 are received, they are 
transferred, in one illustrative embodiment, to a local 
area network processing server. 

In block 68, the validity of the call record 
5 data 66 is checked. The system searches for anomalies 
in the data by performing statistical analysis to 
determine if certain variables fall within established 
parameters. Examples of variables that are analyzed 
include the number of calls received, the number of busy 

10 calls received and the number of calls for which the 
status is unknown in a given time period. The system- 
may also check to ensure that calls were received during 
all hours of the day to determine whether data 
transmission problems were encountered during any time 

15 of the day, or to determine whether the system was: 
temporarily down during any part of the day. The 
current data is compared to collected statistical data 
to determine if the current data is generally in line 
with the collected data. The parameters will vary from 

20 one subscriber to another. For example, for one 
subscriber it may be acceptable for five percent of its 
calls to be of unknown status, . while for another 
subscriber, one percent may be the highest acceptable 
percentage of calls of unknown status. The system 

25 adjusts the parameters over time and for new situations 
as new statistical data is collected.. The validity 
check is performed at the overall level, as well as the 
individual subscriber level. For example, at the 
overall level, the system compares the newly received 

30 files 66, in the aggregate against the statistical data 
maintained for aggregate files. Then, the same types of 
checks are performed on the individual customer basis. 
If the call record data is deemed invalid, it is kicked 
out of the system and not processed further, as shown in 
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block 70. If the data is deemed valid, processing 
continues at block 72. 

In block 72, the system verifies that the 
subscriber's account was active when the particular call 
was placed. If the account was terminated or not yet 
active, the data is not processed, as shown in block 74. 
In block 76, the call record data is converted into a 
format that is compatible with the service provider's 
geocoding software and report -generating software. Also 
in block 76, the call records are matched to the 
subscriber. In some cases, the telephone company will 
provide the customer number as part of the call record 
data. When that is the case, the system looks up the 
customer records in both a customer master file 78 and 
a line cross-reference file (line xref) 80. The 
customer master file contains customer information 
(related to a given customer number) collected during an 
initial set-up procedure in which the customer's account 
is initialized. The cross-reference file 80 contains a 
cross-reference between particular telephone line 
numbers and customer numbers. If the customer number is 
not in the customer master file 78 and the line number 
is not in the line cross-reference file 80, the call 
record is placed in a spin file for a suitable period of 
time (such as one month) and processing is re-tried at 
that time, as shown in block 82. 

If the telephone company does not provide the 
customer number, the system looks up the customer number 
in the line cross-reference file 80. If the line number 
is not in the line cross-reference file 80, again the 
call record is placed in the spin file for one month, as 
shown in block 82. Thus the output of block 72 is a 
good call record file in the service provider's format 
84 . 
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In block 86, the call record data is geocoded. 
The geocoding process attaches to each call the precise 
longitude and latitude of the geographic centroid, or 
geographic center, of either the zip (postal) code, area 
5 code or exchange code of the second party to the call. 
Five geographic databases 88 are maintained, one each 
for nine-digit zip codes, five-digit zip codes, three- 
digit zip codes, area codes, and exchange codes. Each 
database contains the precise longitude and latitude of 
10 the geographic centroid for each respective zip, area 
and exchange code . Table 1 illustrates the geocoding 
hierarchy. 

In case 1, a nine-digit zip code exists in the 
call record's zip code field. If the same nine-digit 

15 zip code exists in the nine-digit zip code database, the 
longitude and latitude corresponding to that zip code 
are attached to that call. If the nine-digit zip code 
is not contained in the nine-digit database, the system 
looks in the five-digit zip code database for the first 

20 five digits of the nine-digit zip code. If that five 
digit zip code is present, the corresponding longitude 
and latitude are attached to the call. If the first 
five digits are not in the five-digit database, the 
three-digit database is searched for the first three 

25 digits of the nine-digit zip code. The three-digit 
database may be useful, for instance, for new zip codes 
which are not yet cataloged in the five-digit database. 
If the first three digits do not exist in the three- 
digit database, the system searches the exchange code 

30 database (designated npanxx DB in Table 1) for the first 
six digits (designated npanxx) of the line number of the 
second party to the call (i.e., the area code and 
exchange) . The exchange code database contains data 
corresponding to particular exchange codes within 
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particular area codes. An exchange code consists of the 
first three digits of a telephone number after the area 
code. Thus, if a match is found in the exchange code 
database, the longitude and latitude corresponding to 
5 the geographic centroid corresponding to the identified 
area code and exchange are attached to the call record. 
If no match is found in the exchange code database, the 
area code database (designated nap DB in Table 1) is 
searched for the area code (designated npa) of the line 

10 number. If that is unsuccessful, a special 

longitude/latitude value indicating unknown origin is 
attached to the call. 

In case 3, a five-digit zip code is provided, 
in the zip code field. If a five-digit zip code exists 

15 in the call record's zip code field, a protocol similar 
to the above is used as shown in Table 1, beginning with 
a search of the five-digit zip DB and continuing on as 
described with respect to case 1. 

As can be seen in cases 2, 4 and 5, Table 1, 

20 if less than five or between five and nine (i.e., six, 
seven or eight) digits exist in the call record's zip 
code field, the system presumes that the data is invalid 
and uses only the line number in geocoding that call as 
described with respect to case 1 . 

25 The system also assigns a value, shown in the 

far right-hand column of Table 1, to the longitude and 
latitude specification based on its precision. For 
example, when the nine-digit zip code database is used 
to determine the longitude and latitude, a more accurate 

30 approximation of the location of the second party to the 
call is obtained than if the five-digit or three-digit 
databases are used. The assigned value reflects this 
degree of accuracy. The assigned value can also be used 
to indicate the reliability of the data. For example. 
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in cases 2 and 4, it is presumed that the zip code field 
in the call record contains bad data. There is then an 
increased probability that other data in the record, 
including the line number, is also unreliable. The 
5 assigned value reflects this reduced level of 
reliability . 



FIG. 4. In block 86, the customer accumulator and line 
accumulator are also updated. The accumulators tally 

10 the number of call records processed during the current 
cycle for each line and for each subscriber. Cycles are 
illustratively weekly or monthly. The output of block.- 
86 is the call detail data 90 which is the aggregate of. 
the call record data 84 and the corresponding geocoded 

15 data. The call detail records 90 are accumulated until 
the end of the cycle, at which time they are prepared 
for distribution to the subscriber. The call detail 
records are also stored in the customer balance and line, 
balance databases 92, which are used in the validity 

20 checks of block 68 and against which statistical 
analysis is performed. 



detail records which takes place at the end of each 
cycle. The system first obtains the identity of a 
25 customer for which a cycle has ended and to which call 
detail records must be reported. This is indicated by 



records have been processed for the given line or given 
subscriber (depending on whether calls are to be 
30 processed for all of the subscriber's lines or for just 
a given line) during the current cycle. If records have 
been processed, the call detail records 90 are collected 
as shown in block 96. In block 98, the system checks 
whether the number of call detail records 90 is equal to 



The description now continues with respect to 



FIG. 5 illustrates the processing of the call 



block 93. 



In block 94, the system checks whether 
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the value held in the accumulator 100. If it is not, 
there may be a problem with the call detail records 90 
and the process is halted, as shown in block 102. If 
the accumulator 100 agrees with the call detail records, 
5 the calls are sorted as indicated by block 104 and cycle 
processing commences as indicated in block 106. 

In block 108, a customer delivery summary file 
110 is created. This file contains information 
regarding the subscriber's delivery preferences. This 

10 file is created using information obtained from the 
customer master file 78 and line cross-reference file 
80. In block 112, a marketing message file 114 is 
created. The marketing message represented in the 
marketing message file may, for instance, be a logo, 

15 company name or other message and will later be placed 
on the output reports. This message is typically 
created by the telephone company. The customer delivery 
summary file 110 and customer message file 114 are then 
merged into a single summary/message file 116, which is 

20 used to determine whether the reports will be delivered 
to the subscriber in paper form, on floppy disk, or via 
the Internet or other suitable mechanism as shown in 
block 118. 

The report data can be delivered to the 
25 subscriber by any of a variety of methods. The 
subscriber chooses the delivery method. The three basic 
delivery methods described herein are the Internet, 
diskette and paper. Of course, other transmission 
methods may be used as well, such as by direct dial-up 
30 connection, wireless connection, etc. 

The Internet and diskette distribution methods 
are illustrated in FIGS. 6 and 7, respectively. FIGS. 
6 and 7 correspond to block 26 in FIG. 1. In both 
methods, first a file is created in an electronic 
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reporting format, such as a .PDF (paper document format) 
file, as shown in block 120. Then a self -extracting 
.exe (executable) file is created, as shown in block 
122. For web distribution, the files are then copied to 
5 the service provider's Internet server delivery 
directory, as shown in block 124. In block 126, the 
service provider's web page is updated to make the new 
files available to the subscriber. The subscriber can 
then retrieve the files at the service provider's web 

10 site. Illustratively, for diskette distribution, after 
the .PDF and .exe files are created, they are copied to 
the customer service delivery directory, as shown in 
block 128. The files are then copied to floppy disk 130 
and delivered to the subscriber. 

15 If the subscriber takes the paper delivery 

option, the service provider creates an ASCII 
printstream file and a .exe file. The service provider 
then generates the report according to the subscriber's 
instructions and delivers a paper copy to the 

20 subscriber. 



delivery are also illustratively provided with report- 
generating software, which they run on their own 
computer. The subscriber uses the report generating 

25 software to process the delivered data files, including 
the call detail data 90, and generate reports relating 
to the call detail data. The subscriber may, if 
desired, view the raw call detail data 90, a sample of 
which is provided in FIG. 8. The particular embodiment 

30 of call detail data illustrated in FIG. 8 includes the 
following fields: call date 132, call time 134, 
destination number 136, calling party number 138, call 
type 140 (incoming, outgoing), call disposition 142, 
call status 144, call duration 146 (in tenths of 



Subscribers who 



choose 



web or diskette 
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seconds) , calling party name 148, postal (zip) code 150 
of the calling party, longitude 152 and latitude 154 of 
the calling party, and the value 156 assigned to the 
longitude/latitude specification. The call disposition 
5 (disp) 142 and call status (stat) 144 fields work 
together to encode information about the call. For 
example, if call stat = 1 and call disp = 0, the call 
was answered. If call stat = 0 and call disp = 2, the 
line was busy. If call stat = 0 and call disp =3, the 
10 call was not answered. Other items can be encoded as 
well. 

The report generator is capable of producing- 
multitudes of different reports in three basic formats: . 
table, graph or map. Appendix A is illustrative of a 

15 main screen which a user of the report generator 
software would first encounter. A quick summary 158 
provides a brief synopsis of the call detail data. In 
report period box 160, the user can select the dates for- 
which a given report or set of reports should be 

20 generated. Clicking on the "Change Dates" button 162 
with a mouse pulls up a calendar, an illustrative 
example of which is provided in Appendix B. The user 
clicks on the dates on the calendar to select the report 
period. The user is not limited to viewing data from 

25 the most recent time period. Rather, data from previous 
time periods may also be included in the reports. 

In the report set selection box 164 the user 
selects which reports should be generated. The user can 
choose among predefined sets of reports, determined by 

30 the service provider. These predefined report sets lump 
together various reports that may be useful for a 
specific purpose such as marketing or staffing, for 
example . 
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By clicking on the "customize report set" 
button 166, the user can also customize a report set so 
that each time the software is run, a predefined set of 
reports, selected by the user, will be generated. 
5 Clicking on the "customize report set" button pulls up 
a menu such as the one illustrated in Appendix C. The 
menu in Appendix C lists a variety of tables, graphs and 
maps. Other menus listing various other tables ,* graphs 
and maps can be accessed by clicking on the various 

10 buttons above the menu. To select which reports should 
be generated, the user clicks on the boxes 170 
corresponding to the desired reports, . In box 172, the 
user can select whether to have reports generated for 
incoming calls, outgoing calls, or both. At circle 174, 

15 the user can select to have reports generated for all of 
its lines, for a particular line, or for a selected 
group of lines. 

Referring again to Appendix A, to view the 
selected reports, the user clicks on the "view reports" 

20 button 176. Appendix D provides an example of a table 
generated by the system. The table lists all of the zip 
codes from which calls were received in the given time 
period for the first time, and ranks them in terms of 
number of calls. Such information may be useful in 

25 developing and analyzing marketing and advertising 
strategies. The data in this table could also be 
presented in graph form, as could the data from any 
generated table. 

Appendix E provides an example of a graph 

3 0 generated by the system. The graph shows the quantity 
of the various call types (answered, busy, unanswered, 
unknown) received during each hour for the given day. 
Such information may be useful in making staffing 
decisions. Of course, the system can also be configured 
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to suggest answers to such decisions. For example, the 
system can be programmed with any desired staffing or 
business parameters (such as a number of calls which can 
be serviced by an individual, and a maximum desired 
5 number of unanswered calls) . With that information, the 
system can analyze the collected information and make 
recommendations, such as "Add an operator from 10:00 am 
to 1:00 pm on Thursdays" or "You average 20 unanswered 
calls between 6:00 am and 8:00 am. Modify store hours 
10 to accommodate incoming calls as early as 6:00 am." Any 
other desired parameters and recommendations can be 
implemented as well. 



be generated by the system include various information 
15 regarding, for example, top callers, top zip codes, new 
callers, call duration, unanswered calls and busy 
signals. Of course, all of this data can be reported 
for either incoming calls, outgoing calls, or both. 



20 form. Appendix F provides an example of a map generated 
by the system. The map indicates the zip codes from 
which the most calls were received by color-coding each 
zip code according to the quantity of calls. 



25 a map at its precise geocoded longitude and latitude. 
Appendix G provides an example of a map that utilizes 
geocoded information. The map shows all incoming calls 
for the stated time period and indicates which day they 
were placed using color-coding. A square is placed for 

3 0 each call at the exact longitude and latitude determined 
by the geocoding process of block 86 in FIG. 4. Using 
geocoded data, the system can also map the location of, 
for example, top callers, new callers, unanswered calls 
and calls that received a busy signal. 



Some of the other tables and graphs that may 



Many reports can also be generated in map 



The software can place each call or caller on 
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Although the present invention has been 
described with reference to preferred embodiments, 
workers skilled in the art will recognize that changes 
may be made in form and detail without departing from 
5 the spirit and scope of the invention. 



